@psss Is anything important missing from the release notes?

Should we wait for teemtee/fmf#249?

Probably should just wait for the dependencies to catch-up with python3.13 rebuilds. Testing fmf and building tmt on rawhide are both stuck on:

Problem: conflicting requests
  - nothing provides python3.12dist(jsonschema) needed by python3-fmf-1.4.0-1.fc41.noarch from fedora
  - nothing provides python3.12dist(ruamel-yaml) needed by python3-fmf-1.4.0-1.fc41.noarch from fedora
  - nothing provides python3.12dist(filelock) needed by python3-fmf-1.4.0-1.fc41.noarch from fedora
  - nothing provides python(abi) = 3.12 needed by python3-fmf-1.4.0-1.fc41.noarch from fedora

        Problem: conflicting requests
          - nothing provides python(abi) = 3.12 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python3.12dist(jinja2) >= 2.11.3 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python3.12dist(requests) >= 2.25.1 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python3.12dist(docutils) >= 0.16 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides ((python3.12dist(click) < 8.1.4 or python3.12dist(click) > 8.1.4) with python3.12dist(click) >= 8.0.3) needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides (python3.12dist(pint) < 0.20~~ with python3.12dist(pint) >= 0.16.1) needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides (python3.12dist(urllib3) < 3~~ with python3.12dist(urllib3) >= 1.26.5) needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python3.12dist(pygments) >= 2.7.4 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python3.12dist(ruamel-yaml) >= 0.16.6 needed by tmt-1.33.0-1.fc41.noarch from rawhide
          - nothing provides python(abi) = 3.12 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides python3.12dist(jinja2) >= 2.11.3 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides python3.12dist(requests) >= 2.25.1 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides python3.12dist(docutils) >= 0.16 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides ((python3.12dist(click) < 8.1.4 or python3.12dist(click) > 8.1.4) with python3.12dist(click) >= 8.0.3) needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides (python3.12dist(pint) < 0.20~~ with python3.12dist(pint) >= 0.16.1) needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides (python3.12dist(urllib3) < 3~~ with python3.12dist(urllib3) >= 1.26.5) needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides python3.12dist(pygments) >= 2.7.4 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
          - nothing provides python3.12dist(ruamel-yaml) >= 0.16.6 needed by tmt-1.33.0-1.fc41.noarch from testing-farm-tag-repository
        You can try to add to command line:
          --skip-broken to skip uninstallable packages

What's even more fun is if any of those packages use tmt for gating.

There is something weird here though. tmt did not get a Rebuild for Python3.13 commit. cmake received it so I don't think it's handled by the repo name. Maybe there is some metadata missing?

Probably should just wait for the dependencies to catch-up with python3.13 rebuilds. Testing fmf and building tmt on rawhide are both stuck on:
tmt rpm build
or
fmf testing

What's even more fun is if any of those packages use tmt for gating.

There is something weird here though. tmt did not get a Rebuild for Python3.13 commit. cmake received it so I don't think it's handled by the repo name. Maybe there is some metadata missing?

Afaik, it should be just the fmf that's causing the F41 py313 builds to fail.

Afaik, it should be just the fmf that's causing the F41 py313 builds to fail.

Build wise you're probably right. On fmf side, it's blocked by tmt FTI issue, so probably can't test either of them without some shenanigans.

@LecrisUT the 'tmt' integration tests failure (rawhide) for fmf update will be ignored.

There is something weird here though. tmt did not get a Rebuild for Python3.13 commit. cmake received it so I don't think it's handled by the repo name. Maybe there is some metadata missing?

@LecrisUT It did receive the attempt, but teemtee/fmf#246 was blocking the build. And we didn't check bugzilla... where python-maint team filed it (as they should).

Should we wait for teemtee/fmf#249?

@martinhoyer Almost there: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e7393d5d0c

Should we wait for teemtee/fmf#249?

@martinhoyer Almost there: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e7393d5d0c

I can see 1.4.1 in rawhide, but rawhide rpm-build here still uses 1.4.0. Any clues why?

@martinhoyer Probably a time problem - https://docs.fedoraproject.org/en-US/releases/rawhide/#_producing_rawhide
If I read it correctly it could be in repos in the afternoon CEST (7am compose + 5-8hours)

FTR, I finally managed to get fmf-1.4.1-1.fc41.noarch installed in fedora:rawhide container

FTR, I finally managed to get fmf-1.4.1-1.fc41.noarch installed in fedora:rawhide container

So I guess I tried it like 5 mins too soon :)
Do we need packit test command or something for the rest of the tests? I forgot 🤡

@martinhoyer The label should be enough, but those jobs (*:full) seem to be stuck. @thrix?

aand the rawhide pip install test will die, because of jsonschema.
There is rpds-py dependency, which needs to compile (uses maturin) and that just won't work until 3.13 is released/supported.
jsonschema<4.18 works, but that conflicts with newer version in Rawhide.

Probably shouldn't block the release.

EDIT: looks like 3.13 will be in PyO3 soon

Probably shouldn't block the release.

ACK, rpms exist, pip + rawhide is not (hopefully) widely used :)

Do we need packit test command or something for the rest of the tests? I forgot 🤡

Yes, packit does not start jobs upon adding a label unless there is an update of the branch or /packit test command.

/packit test

An interesting failure in the /tests/unit/with-system-packages/extended test:

No match for argument: tree-but-spelled-wrong
History database is not writable: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config
History database is not writable: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config
Error: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config

@happz, have you already seen anything like this?

An interesting failure in the /tests/unit/with-system-packages/extended test:

No match for argument: tree-but-spelled-wrong
History database is not writable: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config
History database is not writable: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config
Error: SQLite error on "/var/lib/dnf/history.sqlite": Executing an SQL statement failed: no such table: config

@happz, have you already seen anything like this?

That's the debuginfo-install on coreos.
see: #3014
(also kinda #2974)

Indeed, the cause is in mixing various package manager when building the custom image for our tests. #3014 would address it.

Indeed, the cause is in mixing various package manager when building the custom image for our tests. #3014 would address it.

Do we have a simple reproducer for that ? Would be nice to file it for dnf....

Here's what I debugged so far, fedora-coreos/rawhide has dnf5 already installed, and running the commands there does not error. fedora-coreos/stable needs to first install it with rpm-ostree install dnf5. When you run any dnf commands, the history is recorded properly, but these are not stored inside /var/lib/dnf/history.sqlite. But then when you run debuginfo-install this file is created but on /stable it is empty, while on /rawhide it gets properly migrated first. If you run dnf5 history after that, the commands done by debuginfo-install are not recorded there.

Overall this seems to be a "bug" fixed in rawhide but not ported to stable yet, but maybe it should not be using /var/lib/dnf/history.sqlite in the first place

Do we have a simple reproducer for that ? Would be nice to file it for dnf....

If you mean file it as a bug on dnf, I'm quite sure that what is being done by the tmt test is "not supported" :)